Ceci est le guide pratique sur la façon de configurer un serveur de messagerie utilisant maddy pour un usage personnel. Il omet la plupart des détails techniques par souci de concision et vous donne simplement la liste minimale des éléments dont vous devez être conscient et des mesures à prendre pour que les choses fonctionnent.

Pour des raisons de clarté, ces valeurs sont utilisées dans ce didacticiel à titre d'exemple. Partout où vous les voyez, vous devez les remplacer par vos valeurs réelles :

• •Domaine : exemple.org  

• •Domaine MX (nom d'hôte) : mx1.example.org  

• •Adresse IPv4 : 10.2.3.4  

• •Adresse IPv6 : 2001 : bœuf : 1  

Où trouver un serveur sur lequel exécuter Maddy sort du cadre de cet article. N'importe quel VPS (serveur privé virtuel) fonctionnera parfaitement pour les petites configurations. Cependant, il y a quelques points à garder à l’esprit :

• •Assurez-vous que votre fournisseur ne bloque pas le trafic SMTP (port TCP 25). La plupart des fournisseurs de VPS ne le font pas, mais certains fournisseurs de « cloud » (comme Google Cloud) le font, vous ne pouvez donc pas y héberger votre courrier. 

• •Il est recommandé d'exécuter votre propre résolveur DNS avec la vérification DNSSEC activée. 

Vos options sont :

Si vous avez construit Maddy à partir des sources et que vous l'avez utilisé ./build.sh install, les fichiers d'unité systemd devraient déjà être installés. Si vous avez utilisé une archive tar prédéfinie, copiez- systemd/*.servicela /etc/systemd/systemmanuellement.

Vous devez recharger la configuration du gestionnaire de services pour rendre le service disponible :

systemctl daemon-reload

De plus, vous devez créer un utilisateur et un groupe Maddy. Contrairement à la plupart des autres serveurs de messagerie Linux, maddy ne s'exécute jamais en tant que root.

useradd -mrU -s /sbin/nologin -d /var/lib/maddy -c "maddy mail server" maddy

Ouvrez /etc/maddy/maddy.conf avec  votre éditeur préféré et modifiez les lignes suivantes pour qu'elles correspondent au nom de votre serveur et au domaine pour lequel vous souhaitez gérer le courrier. Si vous configurez un très petit serveur de messagerie, vous pouvez utiliser example.org dans les deux champs. Cependant, pour faciliter une future migration du service, il est recommandé d'utiliser une entrée DNS distincte à cet effet. Il s'agit généralement de mx1.example.org, mx2, etc. Vous pouvez bien sûr utiliser un autre sous-domaine, par exemple : smtp1.example.org. Un serveur de basculement de courrier électronique deviendra possible si vous transférez mx2.example.org vers un autre serveur (à condition que vous le configuriez pour gérer votre domaine).

$(hostname) = mx1.example.org

$(primary_domain) = example.org

Si vous souhaitez gérer plusieurs domaines, vous devez toujours en désigner un comme « principal ». Ajoutez tous les autres domaines à la lignelocal_domains :

$(local_domains) = $(primary_domain) example.com other.example.com

Les certificats TLS sont une chose qui ne peut pas être configurée automatiquement. Si vous les avez déjà quelque part, utilisez-les, ouvrez /etc/maddy/maddy.conf et insérez les bons chemins. Vous devez vous assurer que maddy peut les lire tout en s'exécutant en tant qu'utilisateur non privilégié (maddy ne s'exécute jamais en tant que root, même au démarrage). -up), une façon de le faire est d'utiliser les ACL (remplacez-les par vos chemins réels) :

$ sudo setfacl -R -m u:maddy:rX /etc/ssl/mx1.example.org.crt /etc/ssl/mx1.example.org.key

maddy recharge les certificats TLS à partir du disque une fois par minute afin de remarquer le renouvellement. Il est possible de forcer le rechargement via systemctl reload maddy(ou simplement killall -USR2 maddy).

Si vous utilisez certbot pour gérer vos certificats, vous pouvez simplement créer un lien symbolique /etc/maddy/certs dans /etc/letsencrypt/live. maddy choisira le bon certificat en fonction du domaine que vous avez spécifié lors de l'installation.

Cependant, vous devez toujours rendre les clés lisibles pour Maddy :

$ sudo setfacl -R -m u:maddy:rX /etc/letsencrypt/{live,archive}

Si vous utilisez acme.sh pour gérer vos certificats, vous pouvez simplement exécuter :

mkdir -p /etc/maddy/certs/mx1.example.org

acme.sh --force --install-cert -d mx1.example.org \

  --key-file       /etc/maddy/certs/mx1.example.org/privkey.pem  \

  --fullchain-file /etc/maddy/certs/mx1.example.org/fullchain.pem

systemctl start maddy

Le démon devrait être exécuté maintenant, sauf qu'il est inutile car nous n'avons pas configuré les enregistrements DNS.

La façon dont il est configuré dépend de votre fournisseur DNS (ou serveur, si vous utilisez le vôtre). Voici à quoi devrait ressembler votre zone DNS :

; Basic domain->IP records, you probably already have them.

example.org.   A     10.2.3.4

example.org.   AAAA  2001:beef::1

; It says that "server mx1.example.org is handling messages for example.org".

example.org.   MX    10 mx1.example.org.

; Of course, mx1 should have A/AAAA entry as well:

mx1.example.org.   A     10.2.3.4

mx1.example.org.   AAAA  2001:beef::1

; Use SPF to say that the servers in "MX" above are allowed to send email

; for this domain, and nobody else.

example.org.     TXT   "v=spf1 mx ~all"

; It is recommended to server SPF record for both domain and MX hostname

mx1.example.org. TXT   "v=spf1 a ~all"

; Opt-in into DMARC with permissive policy and request reports about broken

; messages.

_dmarc.example.org.   TXT    "v=DMARC1; p=quarantine; ruf=mailto:postmaster@example.org"

; Mark domain as MTA-STS compatible (see the next section)

; and request reports about failures to be sent to postmaster@example.org

_mta-sts.example.org.   TXT    "v=STSv1; id=1"

_smtp._tls.example.org. TXT    "v=TLSRPTv1;rua=mailto:postmaster@example.org"

Et la dernière, la clé DKIM, est un peu délicate. maddy a généré une clé pour vous au premier démarrage. Vous pouvez le trouver dans /var/lib/maddy/dkim_keys/example.org_default.dns. Vous devez le mettre dans un enregistrement TXT pour default._domainkey.example.org.le domaine, comme ça :

default._domainkey.example.org.    TXT   "v=DKIM1; k=ed25519; p=nAcUUozPlhc4VPhp7hZl+owES7j7OlEv0laaDEDBAqg="

Par défaut, SMTP n'est pas protégé contre les attaques actives. La politique MTA-STS indique aux expéditeurs compatibles de toujours utiliser TLS correctement authentifié lorsqu'ils communiquent avec votre serveur, offrant ainsi un moyen simple à déployer de protéger votre serveur contre les attaques MitM sur le port 25.

Fondamentalement, vous devez créer un fichier avec le contenu suivant et le rendre disponible sur https://mta-sts.example.org/.well-known/mta-sts.txt :

version: STSv1

mode: enforce

max_age: 604800

mx: mx1.example.org

Remarque : mx1.example.org dans le fichier est votre nom d'hôte MX. Dans une configuration simple, ce sera le même que votre nom d'hôte example.org. Dans une configuration plus complexe, vous auriez plusieurs serveurs MX - ajoutez-les tous une fois par ligne, comme ceci :

mx: mx1.example.org

mx: mx2.example.org

Il est également recommandé de définir un enregistrement TLSA (DANE). Utilisez https://www.huque.com/bin/gen_tlsa pour en générer un. Définissez le port sur 25, le protocole de transport sur "tcp" et le nom de domaine sur le nom d'hôte MX . Exemple d'enregistrement valide :

_25._tcp.mx1.example.org. TLSA 3 1 1 7f59d873a70e224b184c95a4eb54caa9621e47d48b4a25d312d83d96e3498238

Un serveur de messagerie est inutile sans boîtes aux lettres, n'est-ce pas ? Contrairement aux logiciels comme postfix et dovecot, maddy utilise des « utilisateurs virtuels » par défaut, ce qui signifie qu'il ne se soucie pas des utilisateurs du système et ne les connaît pas.

Les boîtes aux lettres IMAP (« comptes ») et les informations d'authentification sont conservées séparément.

Pour enregistrer les informations d'identification de l'utilisateur, utilisez maddy creds createla commande. Comme ça:

$ maddy creds create postmaster@example.org

Notez que le nom d'utilisateur est une adresse e-mail. Ceci est requis car le nom d'utilisateur est utilisé pour autoriser l'accès IMAP et SMTP (sauf si vous configurez des mappages personnalisés, non décrits ici).

Après avoir enregistré les informations d'identification de l'utilisateur, vous devez également créer un compte de stockage local :

$ maddy imap-acct create postmaster@example.org

C'est ça. Vous avez maintenant votre première adresse e-mail. lors de l'authentification à l'aide de votre client de messagerie, n'oubliez pas que le nom d'utilisateur est "postmaster@example.org", et pas seulement "postmaster".

Vous pouvez trouver cela opérationnel maddy creds --helpet maddy imap-acct --helputile pour en savoir plus sur d'autres commandes. Notez que les comptes et les informations d'identification IMAP sont gérés séparément, mais les noms d'utilisateur doivent correspondre par défaut pour que tout fonctionne.

Par défaut, maddy utilise les adresses e-mail comme identifiants de compte à des fins d'authentification et de stockage. Par conséquent, le compte nommé user@example.org estcomplètement indépendant de user@example.com. Ils doivent être créés séparément, peuvent avoir des informations d'identification différentes et avoir des boîtes aux lettres IMAP distinctes.

Cela rend extrêmement facile la configuration de Maddy pour gérer plusieurs domaines autrement indépendants.

Le fichier de configuration par défaut contient deux macros - $(primary_domain)et $(local_domains). Ils sont utilisés à plusieurs endroits du fichier pour configurer le routage des messages, les contrôles de sécurité, etc.

En général, vous devez simplement ajouter tous les domaines que vous souhaitez que Maddy gère $(local_domains), comme ceci :

$(primary_domain) = example.org

$(local_domains) = $(primary_domain) example.com

Notez que vous devez choisir un domaine comme « principal » à utiliser dans les messages générés automatiquement.

Cela fait, vous pouvez créer des comptes en utilisant les deux domaines dans le nom, envoyer et recevoir des messages, etc. N'oubliez pas de configurer les enregistrements SPF, DMARC et MTA-STS correspondants.

Notez également que vous n'avez pas vraiment besoin d'un certificat TLS distinct pour chaque domaine géré. Vous pouvez avoir un nom d'hôte, par exemple mail.example.org, défini comme enregistrement MX pour plusieurs domaines.

Si vous souhaitez que plusieurs domaines partagent l'espace de noms de nom d'utilisateur , vous devez modifier plusieurs options supplémentaires.

Vous pouvez faire en sorte que les utilisateurs "user@example.org" et "user@example.com" partagent les mêmes informations d'identification de l'utilisateur "user" mais aient des boîtes aux lettres IMAP différentes ("user@example.org" et "user@example.com" en conséquence. ). Pour cela, il suffit de définir auth_map globalement  pour utiliser la table email_localpart :

auth_map email_localpart

De cette façon, lorsque l'utilisateur se connecte en tant que « user@example.org », « user » sera transmis au fournisseur d'authentification, mais « user@example.org » sera transmis au backend de stockage. Vous devez créer des comptes comme celui-ci :

maddy creds create user

maddy imap-acct create user@example.org

maddy imap-acct create user@example.com

Si vous souhaitez que les comptes partagent également le même stockage IMAP du compte nommé "user" , vous pouvez définir le point de terminaison storage_map et IMAP et delivery_map dans le backend de stockage pour utiliser email_locapart :

storage.imapsql local_mailboxes {

   ...

   delivery_map email_localpart # deliver "user@*" to "user"

}

imap tls://0.0.0.0:993 {

   ...

   storage &local_mailboxes

   ...

   storage_map email_localpart # "user@*" accesses "user" mailbox

}

Vous souhaiterez peut-être également permettre la connexion sans spécifier de domaine du tout. Dans ce cas, utilisez à la fois email_localpart_optional et auth_mapet storage_map.

Vous devez également faire en sorte que la vérification authorize_sender (utilisée dans submissionle point de terminaison) accepte les noms d'utilisateur autres que les e-mails :

authorize_sender {

  ...

  user_to_email chain {

    step email_localpart_optional           # remove domain from username if present

    step email_with_domain $(local_domains) # expand username with all allowed domains

  }

}

Vos options :

"user@example.org" et "user@example.com" ont des informations d'identification et des boîtes aux lettres distinctes.

$(primary_domain) = example.org

$(local_domains) = example.org example.com

Créez des comptes en tant que :

maddy creds create user@example.org

maddy imap-acct create user@example.org

maddy creds create user@example.com

maddy imap-acct create user@example.com

"user@example.org" et "user@example.com" ont les mêmes informations d'identification mais des boîtes aux lettres distinctes.

$(primary_domain) = example.org

$(local_domains) = example.org example.com

auth_map email_localpart

Créez des comptes en tant que :

maddy creds create user

maddy imap-acct create user@example.org

maddy imap-acct create user@example.com

"user@example.org", "user@example.com", "user" ont les mêmes informations d'identification et les mêmes boîtes aux lettres.

   $(primary_domain) = example.org

   $(local_domains) = example.org example.com

   auth_map email_localpart_optional # authenticating as "user@*" checks credentials for "user"

   storage.imapsql local_mailboxes {

      ...

      delivery_map email_localpart_optional # deliver "user@*" to "user" mailbox

   }

   imap tls://0.0.0.0:993 {

      ...

      storage_map email_localpart_optional # authenticating as "user@*" accesses "user" mailboxes

   }

   submission tls://0.0.0.0:465 {

      check {

        authorize_sender {

          ...

          user_to_email chain {

            step email_localpart_optional           # remove domain from username if present

            step email_with_domain $(local_domains) # expand username with all allowed domains

          }

        }

      }

      ...

   }

Créez des comptes en tant que :

maddy creds create user

maddy imap-acct create user